Problem

When PR #112 merged, the Zola deploy job succeeded and pushed to gh-pages, but the subsequent pages build and deployment (GitHub Pages' own publish step) hung for 7+ minutes (normal is ~45s), so the new content never went live. Cancelling the stuck run and re-dispatching the deploy fixed it — but the underlying workflow had no protection against this.

Cause

deploy.yml has no concurrency control. The deploy uses shalzz/zola-deploy-action, which force-pushes to gh-pages. If two runs ever overlap (fast successive merges, a manual re-run racing the push-triggered run, etc.), they stomp on gh-pages and can leave the Pages deployment wedged.

Fix

Add a workflow-level concurrency group so deploys serialize instead of racing:

concurrency:
  group: pages-${{ github.ref }}
  cancel-in-progress: false   # queue; never interrupt a half-finished push

cancel-in-progress: false queues runs rather than cancelling, so a deploy that's mid-push to gh-pages is never interrupted.

Recommended follow-up (settings, not code)

Make the Zola check a required status check on master (branch protection) so a PR can't be merged before its build finishes — which is what prompted this investigation.